Setup

🕒 Created: 2025-01-03 | Updated: 2026-01-23

The folder path on Windows 10 cannot have accented characters, otherwise it will fail.
Windows has a problem with very deep directory structures that the Swift Build system can produce, and this is compounded by the default location of files that you might have, something like C:\Users\Users\migueldeicaza\Documents\GitHub\Experiments\MyGames and you find yourself with odd errors.
You should use the subst command in Windows to map a new drive to that path.
The issue of shared libraries comes down to the extension name of shared libraries (you need to use .dll instead of .dylib or .so ) when describing those in your extension file.
You will also need to copy the Swift standard library DLLs. The default installer adds them to C:/Users/[USER]/AppData/Local/Programs/Swift/Runtimes/[Swift Version]/usr/bin

Debug:
- swift build / swift build --configuration debug / swift build -c debug
Release:
- swift build -c release
Debug vs Release
- .

For a library, the output will be a .dll file.
A dynamic package or dynamic framework is a module that is loaded dynamically at runtime.
Key characteristics:
- Runtime loading : The framework code is loaded when the application runs, not at compile time.
- Reusability : Can be shared among multiple processes or applications, as it is a separate binary.
- Smaller final binary size : Since the framework is not embedded directly into the application binary, the final app size may be smaller.
- Independent updates : The framework can be updated without recompiling the application that uses it.
- Performance : May be slightly slower due to an additional runtime loading step.
Example use:
- Used when the framework needs to be shared between multiple applications.
- Large libraries that do not need to be embedded directly into the binary.

For a library, the output will be a .lib file.
A static package or static framework is a module whose code is linked directly into the final application binary at compile time.
Key characteristics:
- Compile-time loading : All framework code is embedded directly in the final binary during compilation.
- Independence : The final binary includes everything needed, making it independent of external frameworks at runtime.
- Larger final binary size : Because the framework code is embedded in the binary, the final app size increases.
- Performance : Generally faster, as there is no additional runtime loading cost.
- Updates : Any change in the framework requires recompilation of the application.
Example use:
- Used in libraries that need to be fully integrated into the final binary.
- Scenarios where performance is critical and simplicity in distribution is desired.

.dll (Dynamic Link Library) :
- A dynamic library that can be loaded and linked at runtime.
- Used by Godot to integrate extensions and expose the functions and classes created in the extension.
.lib (Static Library or Import Library) :
- Can be a static library (code embedded directly into the final binary) or an "import library" (used only as a reference to link the corresponding .dll ).
- Godot does not use .lib directly because a static .lib must be linked at the compilation of the main executable, and Godot does not recompile its core with the extension.